Wiki gardening rules
내가 옵시디언에 노트를 정리하며 적용하고 있는 정리 규칙.
폴더 되도록 안쓰기
폴더는 정보를 왜곡하고(지배적 분해에 의한 폭정) 파편화하며, 우연한 발견 가능성을 줄이기 때문에 좋지 않다. 폴더는 배타적 소속성이 명확한 경우에 한하여 최소한으로만 사용하며 중첩해서 쓰지 않는다. 즉, 폴더 안에 폴더를 만들지 않는다.
현재 사용 중인 폴더:
/dates: 날짜 모음/media: 영상 및 음악 매체 모음/people: 인물 모음 (가상 인물 포함)/publications: 책, 논문, 기사 등 출판물 모음/: 나머지 모두
태그 안쓰기
배타적 소속성을 강제하지 않는다는 점에서 태그가 폴더보다 좋지만, 자료의 양이 증가함에 따라 태그의 이점은 점점 줄어든다. 왜냐하면 태그의 이점은 다음 두 조건이 성립해야 발휘되기 때문이다.
- 태그가 지나치게 많지 않을 것: 태그가 너무 많아지면 관리 비용이 커지고 태그를 붙이거나 태그로 검색할 때 기억 부담이 커진다.
- 하나의 태그에 속한 자료가 지나치게 많지 않을 것: 특정 태그로 검색한 결과가 지나치게 많으면 검색의 효용이 낮아진다. 특히 랭킹(어떤 자료가 중요한지 우선순위를 세우기)을 부여하기 어렵기 때문에 더욱 그렇다.
그런데 자료가 늘어남에 따라 위 두 가지 조건은 상충하기 시작한다. 하나의 태그에 속한 자료가 지나치게 많지 않으려면 자료가 증가함에 따라 태그의 수도 선형적으로 증가해야 한다. 하지만 태그가 선형적으로 증가하면 태그가 지나치게 많아진다.
태그에 다면 분류(faceted classification)를 적용하면 일부 문제를 개선할 수 있지만 관리와 사용이 복잡해진다.
링크 적극적으로 쓰기
따라서 폴더나 태그 대신 링크를 적극적으로 써서 정보를 분류한다. 링크과 폴더의 근본적인 차이 중 하나는 폴더가 트리 구조인 반면 링크는 그래프 구조라는 점에 있다. (참고: 도시는 나무가 아니다)
몇 가지 규칙들:
- 맥락 살리기: 문서 하단의 “See also” 같은 별도 섹션에 링크를 따로 모아두는 대신, 되도록 본문 텍스트 안에 자연스럽게 링크를 걸어줘서 링크의 맥락을 살린다.
- “See also”는 예외적으로 허용: 맥락 안에 링크를 넣기 어려우면 “임시로” “See also” 섹션에 담아둔다. 시간이 나면 점진적으로 본문을 적당히 수정해서 본문 안으로 옮긴다.
- 외톨이 없애기: 다른 문서와의 링크(역링크 포함)가 하나도 없는 문서를 외톨이(orphan)라고 부른다. 링크로만 구조화를 할 경우 외톨이 문서는 검색 이외의 수단으로 도달할 수 없으므로 외톨이가 있어서는 안된다. 가장 좋은 방법은 새 페이지를 만들 때 일단 기존 링크 어디엔가 링크를 먼저 걸어놓고 시작하는 것.
- 없는 문서에 링크 걸기: 대부분의 위키 엔진에서는 아직 만들어지지 않은 문서에 대한 링크를 미리 걸어둘 수 있는데 이 기능을 적극적으로 사용하면 좋다. 옵시디언을 쓴다면 “Dataview” 플러그인을 이용해서 “Most wanted pages” 목록을 자동으로 관리할 수 있다.
링크를 꾸준히 걸어주려면 지속적인 노력이 필요한데 이는 단점보다는 장점에 가깝다. 새로 생긴 지식과 연결되는 기존 지식을 찾는 과정에서의 의식적 노력이 기억을 상기하고 머릿속에서 지식을 서로 연결시킬 수 있도록 장려하기 때문이다. 모든 과정을 자동화하거나 제거하는 게 항상 좋기만 한 건 아니다. 과정에 담긴 가치가 있기 때문이다.
좋은 이름
문서 사이에 링크가 풍성하게 걸리려면, 그리고 링크가 문맥 안에 자연스럽게 담기려면 문서의 이름을 잘 지어주는 게 중요하다. 프로그래밍을 할 때 변수나 함수 이름을 지어주는 것과 유사하게 충분히 구체적이면서도 되도록 간결하면 좋다.
옵시디언의 별칭 기능도 잘 활용하면 좋다.
점진적으로 꾸준히 관리하기
정리와 구조화는 점진적으로 한다. 예:
- 찾기 어려웠던 문서에 링크 추가하기: 어떤 문서를 찾기가 어려웠다면 다음에 쉽게 찾을 수 있도록 적당한 문서와 이어지는 링크를 추가해준다. 한번에 정리를 완전하게 하는 게 아니라 꾸준히 가꾼다는 느낌.
- 긴 문서 분리하기: 어떤 문서의 내용 중 일부를 지칭하고 싶은 일이 자주 발생하면 문서의 해당 부분만 분리해서 별도의 문서로 만들어준다.
프로그래밍에서 말하는 리팩토링과 같다. 꾸준히 점진적으로 하기. 한번에 완벽하게 하려고 하지 않기.